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(54) Method for two party authentication and key agreement 



(57) According to the two party authentication meth- 
od, a first party generates and transfers a random 
number to a second party as a first challenge. The sec- 
ond party increments a count value in response to the 
first challenge, generates a first challenge response by 
performing a keyed cryptographic function (KCF) on the 
first challenge and the count value using a first key, and 
transfers the count value, as a second challenge, and 
the first challenge response to the first party. The first 
party verifies the second party based on the first chal- 



lenge, the second challenge and the first challenge re- 
sponse. The first party also generates a second chal- 
lenge response by performing the KCF on the second 
challenge using the first key, and transfers the second 
challenge response to the second party. The second 
party verifies the first party based on the second chal- 
lenge and the second challenge response. For instance, 
the first and second parties can be a network and mo- 
bile, respectively, in a wireless system. Also, based on 
the first and second challenges, both the first and sec- 
ond parties may generate another key. 
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Description 
Related Applications 

[0001] The following applications, filed concurrently 
with the subject application, are related to the subject 
application and are hereby incorporated by reference in 
their entirety: application no. unknown entitled METH- 
OD FOR UPDATING SECRET SHARED DATA IN A 
WIRELESS COMMUNICATION SYSTEM by the inven- 
tor of the subject application; application no. unknown 
entitled METHOD FOR TRANSFERRING SENSITIVE 
I NFORMATI ON USING I NT! ALLY UNSECURED COM- 
MUNICATION by the inventor of the subject application; 
application no. unknown entitled METHOD FOR SE- 
CURING OVER-THE-AIR COMMUNICATION IN A 
WIRELESS SYSTEM by the inventor of the subject ap- 
plication; and application no. unknown entitled METH- 
OD FOR ESTABLISHING A KEY USING OVER-THE- 
AIR COMMUNICATION AND PASSWORD PROTO- 
COL AND PASSWORD PROTOCOL by the inventor of 
the subject application and Adam Berenzweig. 

Field Of The Invention 

[0002] The present invention relates to a method for 
authenticating parties communicating with one another, 
and in one application, a method for authenticating a 
mobile and a network in wireless communication. The 
present invention further relates to a key agreement 
based on the authentication protocol. 

Description Of Related Art 

[0003] Protocols for authenticating parties communi- 
cating with one another provide a measure of security 
to the communication. Several such protocols are em- 
ployed by the wireless industry and form part of the dif- 
ferent communication standards intheU S., Europe and 
Japan. 

[0004] While the party authentication system and 
method according to the present invention is not limited 
to wireless communication, to promote ease of under- 
standing, the present invention will described in the con- 
text of a wireless system. For this reason, a general 
overview of wireless systems is presented, including a 
discussion of the party authentication protocol used in 
at least one of the standards. 

[0005] The U.S. currently utilizes three major wireless 
systems, with differing standards. The first system is a 
time division multiple access system (TDM A) and is gov- 
erned by IS-136, the second system is a code division 
multiple access (CDMA) system governed by IS-95, and 
the third is the Advanced Mobile Phone System 
(AMPS). All three communication systems use the IS- 
41 standard for intersystem messaging, which defines 
the authentication procedure for call origination, updat- 
ing the secret shared data, and etc. 



[0006] Fig.1 illustrates a wireless system including an 
authentication center (AC) and a home location register 
(HLR) 10, a visiting location register (VLR) 15, and a 
mobile 20. While more than one HLR may be associated 
5 with an AC, currently a one-to-one correspondence ex- 
ists. Consequently, Fig. 1 illustrates the HLR and AC as 
a single entity, even though they are separate. Further- 
more, for simplicity, the remainder of the specification 
will refer to the HLR and AC jointly as the AC/HLR. Also, 
io the VLR sends information to one of a plurality of mobile 
switching centers (MSCs) associated therewith, and 
each MSC sends the information to one of a plurality of 
base stations (BSs) for transmission to the mobile. For 
simplicity, the VLR, MSCs and BSs will be referred to 
is and illustrated as a VLR. Collectively, the ACs, HLRs, 
VLRs, MSCs, and BSs operated by a network provider 
are referred to as a network. 
[0007] A root key, known as the A-key, is stored only 
in the AC/HLR 10 and the mobile 20. There is a second- 
20 ary key, known as Shared Secret Dala SSD, which is 
sent to the VLR 1 5 as the mobile roams (i.e., when the 
mobile is outside its home coverage area). SSD is gen- 
erated from the A-key and a random seed RANDSSD 
using a cryptographic algorithm or function. A crypto- 
25 graphic functbn is a function which generates an output 
having a predetermined number of bits based on a 
range of possible inputs. A keyed cryptographic function 
(KCF) is a type of cryptographic function that operates 
based on a key; for instance, a cryptographic function 
30 which operates on two or more arguments (i.e., inputs) 
wherein one of the arguments is the key. From the out- 
put and knowledge of the KCF in use, the inputs can not 
be determined unless the key is known. Encryption/de- 
cryption algorithms are types of cryptographic functions. 
35 So are one-way functions like pseudo random functions 
(PRFs) and message authentication codes (MACs). 
The expression KCF SK (R N ') represents the KCF of the 
random number R N ' using the session key SK as the 
key. A session key is a key that lasts for a session, and 
40 a session is a period of time such as the length of a call. 
[0008] In the IS-41 protocol, the cryptographic func- 
tion used is CAVE (Cellular Authenticatbn and Voice 
Encryption). When the mobile 20 roams, the VLR 15 in 
that area sends an authentication request to the AC/ 
4S HLR 10, which responds by sending that mobile's SSD. 
Once the VLR 15 has the SSD, It can authenticate the 
mobile 20 independently of the AC/HLR 10. For security 
reasons, the SSD is periodically updated. 
[0009] Fig. 2 illustrates the communication between 
50 the AC/HLR 10, the VLR 15 and the mobile 20 to update 
the SSD. As discussed above, the AC/HLR 10 gener- 
ates a random number seed RANDSSD, and using the 
CAVE algorithm generates a new SSD using the random 
number seed RANDSSD. The SSD is 1 28 bits long. The 
55 first 64 bits serve as a first SSD, referred to as SSDA, 
and the second 64 bits serve as a second SSD, referred 
to as SSDB. As shown in Fig. 2. the AC/HLR 10 provides 
the VLR 15 with the new SSD and the RANDSSD. The 
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VLR 15 then sends the RANDSSD to the mobile 20 
along with a session request SR. The session request 
SR instructs the mobile 20 to perform the SSD update 
protocol which is described in detail below. In response 
to receipt of the RANDSSD and the session request SR ( s 
the mobile 20 uses the CAVE algorithm to generate the 
new SSD using the RANDSSD, and generates a ran- 
dom number R M using a random number generator. The 
mobile sends the random number to the VLR 15. 
The mobile 20 also performs the CAVE algorithm on the io 
random number ^ using the new SSDA as the key. 
This calculation is represented by CAVE^^^m ), 
[0010] One of the VLR 1 5 and the AC/HLR 10, also 
calculates CAVE SSDA (R M ), and sends the result tothe r ^- v 
mobile 20. The mobile 20 authenticates the network if is 
CAVE SSDA (R M ), which it calculated, matches that re- 
ceived from the network. / 

[001 1] Next, and usually after receiving a signal from 
the mobile 20 indicating verification, the VLR 15 gener- 
ates a random number R N , and sends the random 20 
number R N to the mobile 20. Meanwhile, the VLR cal- 
culates CAVE SSDA (R N ). Upon receipt of R^, the mobile 
20 calculates CAVE SSDA (R N ), and sends the result to 
the VLR 15. The VLR 15 authenticates the mobile if 
CAVE SSDA (R N ), which it calculated, matches that ro- 2s 
ceived from the mobile 20. The random numbers R M and 
R N are referred to as challenges, while CAVE SSDA (R M ) 
and CAVE SSDA (R N ) are referred to as challenge re- 
sponses. Once the authentication is complete, the mo- 
bile 20 and the network generate session keys using 30 
SSDB. 

[0012] In this protocol, the SSD is itself used to an- 
swerthe challenges from the mobile 20 and the network. 
This allows an attack when an old RANDSSD and SSD 
pair are revealed. Knowing this pair is enough to query 35 
the mobile 20, and answer its challenge. Thus an attack- 
er can issue an SSD update to the mobile 20, and an- 
swer the challenge from the mobile. Once the revealed 
SSD is accepted, and despite a secure session key 
agreement protocol {i.e., a protocol on communication 40 
between a mobile and a network to establish a session 
key), the attacker can impersonate the network and 
place a call to the mobile 20 under fraudulent identities. 
For example, the impersonator can insert his own caller 
id or name and pretend to be someone else. The attack- 45 
er can pretend to be a credit card company, and ask to 
verify card number and pin. Or even use the telephone 
company name in the caller name field and ask to verify 
calling card numbers, etc. 

so 

Summary Of The Invention 

[0013] In a two party authentication method according 
to the present invention a first party issues a random 
number as a first challenge, and a second party re- 55 
spends with a first challenge response. The first chal- 
lenge response is generated by performing a keyed 
cryptographic function (KCF) on the first challenge and 
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a count value using a first key. The second party incre- 
ments the count value upon receipt of the first challenge, 
and uses the count value as a second challenge. The 
first party verifies the second party based on the first 
challenge and receipt of the second challenge and the 
first challenge response. After verification, the first party 
performs the KCF on the second challenge using the 
first key to generate a second challenge response. 
Based on the second challenge and receipt of the sec- 
ond challenge response, the second party verifies the 
first party. Using the first and second challenges, an en- 
cryption key is generated by both parties. In this manner, 
a different key, the first key, from the encryption key is 
used in answering challenges. The present invention 
has many applications including the wireless industry 
wherein the first and second parties are a network and 
mobile, respectively. 

Brief Description Of The Drawings 

[0014] The present invention will become more fully 
understood from the detailed description given below 
and the accompanying drawings which are given by way 
of illustration only, wherein like reference numerals des- 
ignate corresponding parts in the various drawings, and 
wherein: 

Fig. 1 is a block diagram illustrating the basic com- 
ponents of a wireless system; 

Fig. 2 illustrates the communication between the 
authentication center/home location register, visit- 
ing location register, and the mobile to update the 
secret shared data according to the IS-41 standard; 
and 

Fig. 3 illustrates the communication between the 
network and the mobile to authenticate these two 
parties according to one embodiment of the present 
invention. 

Detailed Description Of The Preferred Embodiments 

[0015] As discussed above, while the party authenti- 
cation system and method according to the present in- 
vention is not limited to wireless communication, to pro- 
mote ease of understanding, the present invention will 
described in the context of a wireless system. More spe- 
cifically, the method or protocol for two party authenti- 
cation according to the present invention will be de- 
scribed as employed by the wireless system shown in 
Fig. 1. 

[001 6] In contrast to the method or protocol discussed 
above with respect to Figs. 1 and 2, in the method ac- 
cording to the present invention, the AC/HLR 10 and the 
mobile 20 also generate another key, referred to as the 
M-key, based on the A-key. For example, the M-key is 
generated by applying a pseudo random function (PRF) 
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indexed by the A-key on a value known to the network 
and the mobile 20. A practical PRF is the well-known 
Data Encryption Standard-Cipher Block Chaining (DES- 
CBC) algorithm from NIST (National Institute of Stand- 
ards). In a preferred embodiment, DES-CBC, indexed 
by the 64-bit A-key on a known value, produces a 64-bit 
M-key. 

[0017] Fig. 3 illustrates the communication between 
the network and the mobile 20 to authenticate these two 
parties according to one embodiment of the present in- 
vention. As shown, the VLR 15 acts as a conduit for 
communication between the AC/HLR 10 and the mobile 
20. More specifically, the authentication protocol ac- 
cording to the present invention is performed between 
the AC and the mobile 20. 

[0018] As shown, one party, the AC/HLR 10, gener- 
ates and sends a random number to the other party, 
the mobile 20. Typically, the AC/HLR 10, in addition to 
sending the random number R N , sends a session re- 
quest SR specifying the type of protocol to be per- 
formed. Protocol types include, for example, call origi- 
nation, secret shared data (SSD) update, call termina- 
tion, and mobile registration. 

[0019] In response, the mobile 20 generates a count 
value C M , and performs a KCF on the random number 
R N , the count value C M , Type data, and id data ID M using 
the M-key as the key. This calculation is represented a 
KCF M-Key0Vpe, ID M , C M , R N ). Preferably, the KCF is a 
keyed message authentication code such as HMAC, but 
could be a PRF such as DES-CBC, The mobile 20 in- 
cludes a counter which generates the count value C M . 
The mobile 20 increments the count value C M prior to 
generating the challenge response (i.e., KCF M . Key 
(Type, ID M , C M , R N )) to each challenge from the net- 
work. 

[0020] The Type data represents the type of protocol 
being performed. The id data indicates that the commu- 
nication issued from the mobile. Usually, id data 1 indi- 
cates that the communication is from the network, and 
id data 0 indicates that the communication came from 
the mobile. For the purposes of discussion, however, the 
id data for the mobile 20 is shown as I D M and the id data 
for the n etwork is shown as I D N . The system and method 
for two party authentication does not require the inclu- 
sion of the Type data when performing the KCF on the 
random number R N and the count value C M . The Type 
data and the specific id data have been included as part 
of the application of the two party authentication method 
and system to a wireless system. 
[0021] The mobile 20 sends count value C M and 
KCF M-Key( Tv Pe. 'D M , C M , R N ) to the network. Because 
the AC/HLR 10 initiated the current protocol including 
the two party authentication protocol according to the 
present invention, the AC/HLR 1 0 knows the Type data. 
Also, because communication from mobiles include the 
same id data, this value is known by the AC/HLR 10 as 
well. Accordingly, based on the received count value 
C M . the AC/HLR 10 calculates KCF^ (Type, ID M , 



c m » r n) and determines whether this calculated value 
matches the version received from the mobile 20. If a 
match is found, the AC/HLR 1 0 authenticates the mobile 
20. 

5 [0022] Once the mobile 20 has been verified, the AC/ 
HLR 10 calculates KCF^^lType, ID N , C M ), and sends 
the calculated result to the mobile 20. The mobile 20, 
meanwhile, calculates KCF M . Key (Type, ID N , C M ) as 
well. The mobile 20 then verifies whether the calculated 

10 version of KCF M . K ey(Type, ID N C M ) matches the ver- 
sion received from the AC/HLR 10. If a match is found, 
the mobile 20 authenticates the network. 
[0023] Furthermore, after performing this two party 
authentication protocol, other keys can be generated. 

75 For instance, if the wireless system of Fig. 1 used this 
two party authentication protocol as part of the SSD up- 
date protocol, then, after the mobile 20 authenticates the 
network, -the mobile 20 and the AC/HLR 10 both have 
the random number Rn and the count value C M . Both 

20 the mobile 20 and AC/HLR 1 0 generate the SSD as PR- 
F A-Key( c M - r n) I wherein the PRF is preferably the DES- 
CBC algorithm. Alternatively, in other protocols, this 
same technique is used to generate other keys. 
[0024] When applied to a wireless system, the mobile 

25 20 needs to store the count value C M in semi-permanent 
memory so that during power down, the count value C M 
is not re-initialized. This way, repetition of a count value 
is prevented; repetition of the count value permits an at- 
tacker to prevail in his attack. In a preferred embodi- 

30 ment, the count value is initialized using a random 
number and generated using a large bit counter such as 
a 64 or 75 bit counter. This provides security even when 
the mobile 20 crashes and loses the stored count value. 
Even if an attacker can cause a mobile to crash at will, 

35 and assuming it takes at least a second to initiate a ses- 
sion, it will take, for example, a year before the attacker 
manages to have the mobile repeat a count value when 
a 75 bit counter is used. 

[0025] As a further alternative, instead of a sending a 
to unique random number R N , the initiating party (e.g., the 
network) issues a global random number. Namely, for 
each communication, the initiating party issues a differ- 
ent, unique random number R N in the embodiment of 
Fig. 3. However, in this alternative embodiment, the in- 
45 itiating party issues the same random number for 
each communication. 

[0026] In the protocol according to the present inven- 
tion the key previously established between the parties 
(e.g., A-key or SSD) is not used to answer challenges, 

so and thus the network impersonation problem discussed 
with respect to IS41 is not possible. Furthermore, even 
if the M-key is revealed to an attacker, there is no direct 
way to obtain the A-key therefrom because a one-way 
function was used to generate the M-key. Because an 

55 attacker uses prior challenges and challenge responses 
when mounting an attack, such an attack will fail if made 
on the protocol according to the present invention. The 
reason is that the attacker will be using a challenge re- 
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sponse based on an old count value. Consequently, the 
network will not verify the attacker. Further, keys gener- 
ated after authentication as discussed above will be 
generated by the PRF of the new challenge using the 
A-key, and the attacker does not know the A-key. s 
[0027] The invention being thus described, it will be 
obvious that the same may be varied in many ways. 
Such variations are not to be regarded as a departure 
from the spirit and scope of the invention, and all such 
modifications are intended to be included within the 10 
scope of the following claims. 

Claims 

is 

1 . A method for authenticating a first party at a second 
party, comprising: 

(a) receiving a random number from said first 
parly as a first challenge; 20 

(b) incrementing a count value in response to 
receiving said first challenge; 

(c) generating a first challenge response by 2s 
performing a keyed cryptographic function 
(KCF) on said first challenge and said count val- 
ue using a first key; 

(d) transferring said count value, as a second 30 
challenge, and said first challenge response to 
said first party; 

(e) receiving a second challenge response from 
said first party, said second challenge response 35 
being a result of performing said KCF on said 
second challenge using said first key; and 

(f) verifying said first party based on said sec- 
ond challenge and said second challenge re- 40 
sponse. 

2. The method of claim 1 , prior to said step (c), further 
comprising: 

(9) generating said first key using a root key 4S 

3. The method of claim 1 , wherein said step (c) gen- 
erates said first challenge response by performing 
said KCF on said first challenge, said count value, 
and an identifier for said second party using said so 
first key. 

4. The method of claim 1 , further comprising: 

(g) establishing a second key based on said 
first and second challenges. ss 

5. The method of claim 1, wherein said step (a) 
eceives a global challenge as said first challenge 
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from said first party. 

6. The method of claim 1 , wherein said first party is a 
network of a wireless system and said second party 
is a mobile. 

7. The method of claim 6, wherein said step (c) gen- 
erates said first challenge response by performing 
said KCF on said first challenge, said count value 
and type data using said first key, said type data 
indicating a type of protocol being performed by 
said network and said mobile. 

8. The method of claim 6, wherein said step (c) gen- 
erates said first challenge response by performing 
said KCF on said first challenge, said count value, 
an identifier for said mobile, and type data using 
said first key, said type data indicating a type of pro- 
tocol being performed by said network and said mo- 
bile. 

9. The method of claim 6, further comprising: 

(g) establishing a second key based on said 
first and second challenges. 

10. The method of claim 9, wherein said second key is 
one of secret shared data and a session key. 

11 . The method of claim 6, wherein said step (b) incre- 
ments said count value using a bit counter of greater 
than 64 bits and which was initialized using a ran- 
dom number 

12. A method for authenticating a first party at a second 
party, comprising: 

(a) outputting a random number as a first chal- 
lenge; 

(b) receiving a second challenge and a first 
challenge response from said first party, said 
second challenge being a count value, and said 
first challenge response being a result of per- 
forming a keyed cryptographic function (KCF) 
on said first challenge and said count value us- 
ing a first key; and 

(e) verifying said first party based on said first 
challenge, said second challenge, and said first 
challenge response. 

13. The method of claim 12, further comprising: 

(f) establishing a second key based on said 
first and second challenges. 

14. The method of claim 12, wherein said step (a) out- 
puts said first challenge as a global challenge. 
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15. The method of claim 12, wherein said first party is 
a mobile of a wireless system and said second party 
is a network. 

1 6. The method of claim 1 5, further comprising: s 

(f) establishing a second key based on said 
first and second challenges. 

17. The method of claim 16, wherein said second key 

is one of secret shared data and a session key. 10 

18. The method of claim 12, further comprising: 

(f ) generating a second challenge response by 
performing said KCF on said second challenge is 
using said first key; and 

(g) transferring said second challenge re- 
sponse to said second party. 

20 

1 9. The method of claim 1 8, wherein said step (f) gen- 
erates said second challenge response by perform- 
ing said KCF on said second challenge and an iden- 
tifier for said second party using said first key. 

25 

20. The method of claim 18, wherein said first party is 
a mobile of a wireless system and said second party 
is a network. 

21. The method of claim 20, wherein said step (f) gen- 
erates said second challenge response by perform- 
ing said KCF on said second challenge and type 
data using said first key, said type data indicating a 
type of protocol being performed by said network 
and said mobile. 

22. The method of claim 20, wherein said step (f ) gen- 
erates said second challenge response by perform- 
ing said KCF on said second challenge, an identifier 
for said network, and type data using said first key, 40 
said type data indicating a type of protocol being 
performed by said network and said mobile. 
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(54) Method for two party authentication and key agreement 



(57) According to the two party authentication meth- 
od, a first party generates and transfers a random 
number to a second party as a first challenge. The sec- 
ond party increments a count value in response to the 
first challenge, generates a first challenge response by 
performing a keyed cryptographic function (KCF) on the 
first challenge and the count value using a first key, and 
transfers the count value, as a second challenge, and 
the first challenge response to the first party. The first 
party verifies the second party based on the first chal- 



lenge, the second challenge and the first challenge re- 
sponse. The first party also generates a second chal- 
lenge response by performing the KCF on the second 
challenge using the first key, and transfers the second 
challenge response to the second party. The second 
party verifies the first party based on the second chal- 
lenge and the second challenge response. For instance, 
the first and second parties can be a network and mo- 
bile, respectively, in a wireless system. Also, based on 
the first and second challenges, both the first and sec- 
ond parties may generate another key. 
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